Check if this issue is valid — if so, understand the root cause and fix it. At crates/daemon/src/handler/mod.rs, line 2215:

<comment>`UpdateDraft` derives its authorization scope from the caller-supplied `draft.account_id` rather than the stored draft's actual account. Because `request_account_scope` returns early via `request_account_id` and never reaches the `draft_account_scope` branch for `UpdateDraft`, an agent restricted to account A can submit a draft ID belonging to account B while setting `draft.account_id = A` in the payload. The profile check passes for A, and `Store::update_draft` explicitly SETs `account_id` on the matched row, allowing the draft to be overwritten and reassigned across accounts.

Scope `UpdateDraft` from the stored draft ID instead: look up the existing draft's account in `request_account_scope` (or validate the payload's `account_id` against the stored row before updating), and consider omitting `account_id` from the UPDATE's SET list for in-place edits.</comment>

<file context>
@@ -2204,6 +2212,7 @@ fn request_account_id(req: &Request) -> Option<&mxr_core::AccountId> {
         Request::GetSyncStatus { account_id } => Some(account_id),
         Request::SendDraft { draft, .. }
         | Request::SaveDraft { draft }
+        | Request::UpdateDraft { draft }
         | Request::SaveDraftToServer { draft }
         | Request::CheckDraftSafety { draft, .. }
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At crates/store/src/draft.rs, line 160:

<comment>`update_draft` performs an unconditional UPDATE with only `id` and `status` in the WHERE clause, so concurrent edits from two clients silently overwrite each other (lost-update). Consider adding an optimistic concurrency check on `updated_at` so the second updater receives a conflict instead of clobbering the first edit.</comment>

<file context>
@@ -133,6 +133,56 @@ impl super::Store {
+        // `created_at` is intentionally absent from SET so the original
+        // creation time survives the edit. Plain UPDATE (not INSERT OR
+        // REPLACE) so the account_id FK's ON DELETE CASCADE is never armed.
+        let result = sqlx::query(
+            "UPDATE drafts
+                SET account_id = ?, in_reply_to = ?, intent = ?,
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At crates/web/src/routes_v6.rs, line 1966:

<comment>The `UpdateDraft`-to-`SaveDraft` fallback in `save_draft_local` can silently resurrect a draft that was deleted in another tab or client. Because the handler only receives a `Draft` payload with no creation intent or version, a \"not found\" error is ambiguous: it may mean the ID is new (intended insert) or that the row was deleted since this editor opened it (unintended resurrection). When multiple compose tabs reuse `intent.draftId` and one deletes the draft, a stale save from another tab will re-insert the deleted row via `SaveDraft`, making deletion non-durable.

**Recommendation**: Pass an explicit upsert intent or guard the insert path so it only runs for client-generated / explicitly-new drafts, not for IDs that originated from a `GetDraft` load.</comment>

<file context>
@@ -1942,20 +1942,39 @@ async fn send_stored_draft(
+    .await
+    {
+        Ok(response) => passthrough(response),
+        Err(BridgeError::Ipc(message)) if message.to_lowercase().contains("not found") => {
+            let response = dispatch(
+                &state,
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At crates/daemon/src/commands/mutations/compose.rs, line 671:

<comment>Using a deterministic scratch filename per `DraftId` and unconditionally unlinking it before writing introduces a destructive race. If a prior edit failed, its recovery content (intended to be kept for the user) is deleted on retry. Worse, two concurrent `mxr drafts edit <id>` processes cause the second invocation to remove the first editor's file from under it, after which both editors may operate on conflicting inodes or the same replacement path. The scratch file should use a unique per-invocation name (e.g. with a random suffix) and cleanup should be scoped to that specific invocation, preserving any unrelated recovery file.</comment>

<file context>
@@ -638,6 +638,86 @@ pub async fn drafts_discard(draft_id: String, account: Option<String>) -> anyhow
+    let content = mxr_compose::draft_codec::draft_to_compose_file(&draft, &from)?;
+    // A draft is unsent mail content; write it to the per-user private 0700
+    // scratch dir with 0600 perms rather than the world-readable temp root.
+    let path = mxr_compose::private_tmp::private_scratch_dir()?
+        .join(format!("mxr-draft-edit-{}.md", draft.id));
+    // Clear any leftover from a prior aborted edit so the O_EXCL write succeeds.
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At crates/tui/src/compose_flow.rs, line 253:

<comment>Using a deterministic scratch filename based only on `DraftId` and unconditionally removing it before writing destroys previously preserved recovery files from failed edits and creates a race between concurrent TUI sessions editing the same draft. Consider a unique per-edit filename and retaining failed files instead.</comment>

<file context>
@@ -229,6 +230,124 @@ pub(crate) async fn handle_compose_action(
+    // Best-effort: clear a stale file left behind by a previous
+    // cancelled/failed edit of this same draft — `write_private` uses
+    // O_EXCL and would otherwise refuse to write.
+    let _ = tokio::fs::remove_file(&path).await;
+    mxr_compose::private_tmp::write_private_async(&path, content.as_bytes())
+        .await
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At crates/daemon/src/commands/mutations/compose.rs, line 685:

<comment>The CLI edit path parses the compose file twice: once explicitly for validation and again inside `draft_codec::apply_edited_compose_file`. This is redundant and means parser behavior changes must be consistent across both paths. Consider refactoring `apply_edited_compose_file` to accept the already-parsed `(&ComposeFrontmatter, &str)` so the caller can reuse the parse it already performed.</comment>

<file context>
@@ -638,6 +638,86 @@ pub async fn drafts_discard(draft_id: String, account: Option<String>) -> anyhow
+    validate_compose_draft(&frontmatter, &body, false)?;
+
+    let updated =
+        mxr_compose::draft_codec::apply_edited_compose_file(&draft, &edited, chrono::Utc::now())?;
+
+    expect_ack(
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At crates/daemon/src/commands/mutations/compose.rs, line 680:

<comment>Stored-draft editing bypasses the snippet expansion that the standard compose-save flow performs. In `finalize_compose`, `expand_compose_snippets_with_context` is called before saving, but `drafts_edit` passes the raw edited text straight into `apply_edited_compose_file`. Because `send_stored_draft` also does not expand snippets before sending, any snippet tokens added during an edit can be sent literally to recipients instead of being resolved. The edit path should expand snippets after the editor returns and before constructing the updated `Draft`, matching the fresh-compose behavior.</comment>

<file context>
@@ -638,6 +638,86 @@ pub async fn drafts_discard(draft_id: String, account: Option<String>) -> anyhow
+    let editor = mxr_compose::editor::resolve_editor(None);
+    mxr_compose::editor::spawn_editor(&editor, &path, None).await?;
+
+    let edited = std::fs::read_to_string(&path)?;
+    let (frontmatter, body) = mxr_compose::frontmatter::parse_compose_file(&edited)?;
+    validate_compose_draft(&frontmatter, &body, false)?;
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At crates/tui/src/compose_flow.rs, line 243:

<comment>Using `resolve_compose_account` for draft editing applies a send-capability eligibility check that is unnecessary for updating an existing draft. Drafts from disabled or non-sending accounts are listed by the daemon but cannot be edited in the TUI because this call rejects them. Use an account lookup that does not require `compose_account_eligible` for the edit path, or filter/label such drafts consistently in the modal.</comment>

<file context>
@@ -229,6 +230,124 @@ pub(crate) async fn handle_compose_action(
+    bg: &mpsc::UnboundedSender<IpcRequest>,
+    draft: Draft,
+) -> Result<DraftEditReadyData, MxrError> {
+    let account = resolve_compose_account(bg, Some(&draft.account_id)).await?;
+    let content = mxr_compose::draft_codec::draft_to_compose_file(&draft, &account.email)
+        .map_err(|e| MxrError::Ipc(e.to_string()))?;
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At crates/tui/src/compose_flow.rs, line 324:

<comment>On non-zero editor exit, the flow displays 'Edit cancelled' and queues deletion of the temp file, assuming the user intentionally discarded changes. But editors (or wrappers like `git rebase --exec` pipelines) can write to disk before exiting non-zero, so this path can silently discard actual edits. Also, when the editor fails to launch (`Err(error)`), the error message does not include the temp file path, unlike the parse/update failure paths which explicitly say 'Your edits are still at …'. Since the PR's design intent for this function is to preserve the temp file and surface its path (as evidenced by the careful error handling around parsing and `UpdateDraft` failures), these two branches are inconsistent and leave gaps for silent content loss.</comment>

<file context>
@@ -229,6 +230,124 @@ pub(crate) async fn handle_compose_action(
+                        ),
+                    );
+                }
+                Ok(_) => {
+                    app.report_error(
+                        "Update Draft Failed",
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At crates/tui/src/compose_flow.rs, line 327:

<comment>When `UpdateDraft` returns an unexpected successful response shape, the scratch file is preserved but its path is not disclosed in the error message, making recovery impossible for the user. Include `data.path.display()` in this branch, matching the adjacent `Response::Error` and transport-error branches.</comment>

<file context>
@@ -229,6 +230,124 @@ pub(crate) async fn handle_compose_action(
+                Ok(_) => {
+                    app.report_error(
+                        "Update Draft Failed",
+                        "Unexpected daemon response to UpdateDraft".to_string(),
+                    );
+                }
</file context>